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ity of access points based on the plurality of metrics for each 
of the plurality of access points, and providing the priority in- 
formation regarding the access points to the client (1050). 
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Method and System for Optimizing Access 
to a Communications Network 

Cross-Reference to Related Applications 

This application claims priority to pending Provisional Application Serial 
No. 60/175,309 (Attorney Docket No. 10120-150), filed January 10, 2000. 

Field of the Invention 

The present invention relates to the field of telecommunications, and, more 
particularly, to a method and system for optimizing access to a communications 
network. 

Brief Description of the Drawings 

The invention will be more readily understood through the following detailed 
description, with reference to the accompanying drawings, in which: 

FIG.l is a flowchart of an embodiment of a method 100 of the present 
invention; 

FIG. 2 is a flowchart of an embodiment of a method 200 of the present 
invention; 

FIG. 3 is a flowchart of an embodiment of a method 300 of the present 
invention; 

FIG. 4 is a flowchart of an embodiment of a method 400 of the present 
invention; 

FIG. 5 is a flowchart of an embodiment of a method 500 of the present 
invention; 

FIG. 6 is a flowchart of an embodiment of a method 600 of the present 
invention; 

FIG. 7 is a block diagram of an embodiment of a system 700 of the present 
invention; and 
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FIG. 8 is a block diagram of an embodiment of an information device 800 of 
the present invention. 

Detailed Description 

5 

Overview 

Embodiments of the invention can enable improved and/or optimized client 
software access to a communication network based on a plurality of variables, such 
that a selected communication interface to the network can provide: 
10 • The highest quality network access (for example, speed, expected longevity 
of connection, etc.) 

• The lowest cost structure 

• Some mix of quality and cost 

• Increased virtual capacity 

15 

Embodiments of the invention can permit the achievement of independent 
goals for different sets of users. For example, in an embodiment of the present 
invention, the system can choose to try to optimize for the lowest cost connections 
for non-paying users, and/or optimize for the highest quality connections for paying 
20 users. 

At least one disclosed embodiment provides an inventive method that 
advantageously includes identifying a plurality of access points for a client to access 
a communication network from a specified location, and obtaining a plurality of 
metrics, including a real-time performance metric, for each of the plurality of access 
25 points. At least one disclosed embodiment of the inventive method also 

advantageously includes determining, using a processor, priority information for 
each of the plurality of access points based on the plurality of metrics for each of the 
plurality of access points, and providing the priority information regarding the 
access points to the client. 
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Thus, certain embodiments of the present invention can be viewed as 
providing dynamically-adjusted priorities for improving and/or optimizing the 
selection of a communication network access provider from a set of such access 
providers. 

Definitions 

• POP (Point of Presence): a phone number (that can be provided by a 
network carrier) that client software can dial into to gain access to the server. 
Also known as an "access point" and/or an "access number". 

• Dial Data Overlays (DDOs): specially encoded strings that can be sent from 
the server to the client software. These strings can include telephone 
numbers and parameters that the client software can: 

1 . display to the user during phone number selection; and/or 

2. use to prioritize phone numbers before dialing a POP. 

• Source Cluster: a collection of parts of source numbers representing local 
telephone exchanges that have the same list of POPs local to them. 

• POP Cluster: a list of POPs local to a Source Cluster. 

• Cluster List: a list of existing POP clusters. 

• Pop Manager: software that can generate and/or update the DDOs. The 
updates can take place regularly, because the variables used in computing the 
DDOs (e.g., historical usage at a particular POP, current failure rates at a 
particular POP, the capacity at a particular POP, the rate structure at a 
particular carrier) can change at any time. 
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• Dialdata File: a file containing dialing information (e.g., phone numbers, 
priorities) that can be used by the client software. 

• Network String: a string generated by the client software that can indicate 
the access number on which communication with the server has been 
successfully established, as well as any other access numbers dialed during 
the same session on which a successful connection was not established. 

• Metered Carrier: a network carrier that charges for each minute of service 
provided to its users. 

• Per Port Carrier: a network carrier that charges a fixed cost per dialing port 
independent of actual usage. To the extent that there exists purchased port 
capacity at the carrier, users can use the carrier's ports without incurring 
additional costs. 

History of the Invention 

Known client software for facilitating access to a communications network 
has been designed to be "network independent". That client software is asked to dial 
into multiple access numbers by using a dialdata file that lists all the telephone 
numbers available for dial-in to the network, a description of the carriers on which 
they operate, and what is called a "fixed priority". Prior to (he present invention, 
clients used this fixed priority to choose between the list of available numbers that 
the user selected. Under this known scheme, the client software looked up each 
number in the dialdata file, extracted its fixed priority value, and used that priority in 
order to build a priority queue from which to start dialing. Frequent updates of the 
dialdata file would not result in the effects claimed by the present invention, and in 
many cases would be prohibitively inefficient. 

The inventors of the present invention have discovered that, if every user had 
the same dialdata file, then every user within the same region would have the same 
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priority queue of access numbers to dial. Upon discovering this substantial problem, 
the inventors of the present invention sought an improved approach. 

Embodiments of the present invention can improve and/or optimize the 
dialing process over the known "fixed priority" scheme in at least the following 
manners: 

Optimizing POP Capacity: 

Consider the simple case of two carriers with the same exact 
coverage and the same cost structure, but one that has 100 ports available for 
use, and one that has 50 available ports. Using the known "fixed priority" 
scheme, one of these carriers (presumably the one with 100 ports) would 
have a higher priority than the one with 50, and all users would first dial into 
the carrier with 100 ports and then fall back to the carrier with 50 ports if the 
carrier having 100 ports had all of those 100 ports filled. 

Embodiments of the present invention can improve the user 
experience by having the client compute a priority at the time of dialing 
based on some random element For example, sixty-six percent of the time, 
the carrier with 100 ports could be prioritized ahead of the carrier with 50 
ports. This could produce an aggregation of available capacity across both 
POPs. From the highest level it would appear that there are 150 available 
ports. Thus, this scheme can create the appearance of extra available 
capacity versus the fixed priority scheme. 

Optimizing Off-Peak Usage: 

Different rate structures are typically available for different carriers. 
For example, company X, which is primarily a business network provider, 
might define peak hours as Monday through Friday, 9am to 5pm. During 
those peak hours, Company X charges a higher per minute charge than 
during the off-peak hours. Another carrier, Y, however, might define peak 
hours as Monday through Friday, in the evening. Therefore, all other things 
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being equal, and coverage being the same, it is more economical to use 
Company X on Monday through Friday in the evenings, and Company Y on 
Monday through Friday during the day, in order to maximize off-peak hour 
usage (as defined by each carrier) across each 24 hour period. This was not 
possible under the known "fixed priority" scheme, but it can be achieved 
with embodiments of the current invention. 

Optimizing Per-Port Usage: 

Consider the notion of trying to maximize the use of the "per port" 
carriers. These are the carriers whose ports are owned and can be utilized 
fully without incurring any additional charge above and beyond the sunk cost 
for acquiring those ports (effectively fixed assets). Embodiments of the 
present invention allow one to construct a system in which usage of fixed 
assets would approach 100% utilization, and spillover connections would be 
sent to other non-fixed assets. 

Features and Advantages of Certain Exemplary Embodiments of the Invention 

Client Use of DDOs 

In certain exemplary embodiments, the client can use DDOs for at 
least two purposes: 

1 . To get POP locality information: 

In some embodiments of the present invention, the first time a 
user selects a "local" phone number into which that user would prefer 
to dial, that user can only choose from a list of numbers that fall 
within the user's area code. For example, a user who lives in the 212 
area code in the United States might only be given the opportunity to 
choose from numbers that exist in the 212 area code. 
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Following the first connection, however, the user's machine 
(the client) can receive a DDO string that lists additional "local" POP 
numbers that might fall outside the user's area code. In the case of 
New York city, this might include numbers from the 718 and other 
area codes. These choices can be made available because they might 
still constitute "local" calls for the user . 

2. To dynamically prioritize POP number selection during dialing: 
In certain embodiments of the invention, the fixed priority 
codes found in the dialdata files can be augmented with functions that 
evaluate dynamic priorities using the DDO strings and other 
information available to the client at the time of the dialing (e.g., time 
of day, user service type). This is described in more detailed in the 
"Server to Client (The DDO String)" section, below. 

Server System for Generating/Updating DDOs 

PopManager - Database Interaction 

In certain exemplary embodiments, the server system can include a 
database management system in communication with the Pop Manager and 
with each of the Servers. The database management system can store various 
POP related information (e.g., phone number, network carrier, cost 
information, cluster information, historical failure rates, DDO strings). The 
database management system can include a high capacity relational database 
and a distributed system of files local to each of the servers. The local files 
can contain up-to-date copies of the DDO related tables found in the 
relational database. 

In certain embodiments, immediately after it is started up, the POP 
Manager can begin obtaining various POP-related data for certain and/or all 
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POPs from the database management system. This data can also be 
refreshed on demand at a later time. The following is a detailed description 
of some of the various data the POP manager can obtain: 

1. General POP Information: 

The general POP information can include: 

• POP Area Code: the POP's area code (or country/city code 
outside North America). 

• POP Number: the POP's phone number. 

• Carrier: the network carrier the POP belongs to (e.g., Sprint). 

• Rate ID: the id of a database entry with the POP's cost rate. 

• Gateway ID: the id of the gateway the POP belongs to. A 
Gateway is a collection of POPs that are billed together as a unit 
by a per-port carrier. 

2. Gateway Information 

The POP Manager can use the gateway information to compare the 
POPs that have metered rates with the POPs that have per port rates (the 
POPs belonging to a gateway). The gateway information can include: 

• Gateway ID: this can be a unique number identifying the 
gateway. 

• Ports: the number of purchased ports (one more purchased port 
allows for one more concurrent connection). 

3. POP Rate Information 

The POP rate information can include: 

• Rate ID: a unique number that can identify the rate. 

• Rate Type: the rate type (e.g., metered or per port). 
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• Protocol: a code that can indicate the connection and user type 
(since the cost rates can be different for different types of 
connections). For example, in a current embodiment of the 
present invention, it can be one of the following: free mail, mail, 

5 free web, web. 

• Price: the actual POP price. 

• Start Time: the starting time of the interval during which the price 
is valid. 

• End Time: the end of the interval during which the price is valid. 
10 • Threshold: a threshold value at which the rate changes. 

• Threshold Type: the type of threshold associated with the rate, 
such as: 

• The point at which the price changes for all subsequent calls. 
For example: the system operator might pay $l/hour for the 

1 5 first 1 0,000 hours, and $0.50/hour after that. 

• The point at which the entire usage rate changes to a lower 
rate. For example, the system operator might pay a rate of 
$l/hour (for all hours used) if it used less than 10,000 hours in 
a month, and a rate of $0.50/hour (for all hours used) if it used 

20 more than 1 0,000 hours in a month. 

• Threshold Group: this can be utilized for usage purposes (for 
example, indicating which carriers count as oneibr billing 
purposes). For example, two merged carriers might issue a 
combined bill. 



25 



4. POP Failure History Information 

The POP Manager can refresh this data at the end of each day 
because the POP's performance can change at any point. The failure history 
data can include: 
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• Protocol: this field can identify the connection and user type for 
this performance information. 

• Time: the date of this performance information. 

• POP area code: the POP's area code. 

• POP number: the POP's phone number. 

• Successes: the number of successful connections for the specified 
time. 

• Failures: the number of failed connections for the specified time. 

5. Pop Cluster List 

The POP cluster list can include: 

• Cluster ID: a unique number that can identify a particular cluster. 

• Optimization Flag: this field can indicate whether the Pop 
Manager should attempt to generate DDOs for this particular 
cluster. 

Pop Manager - Servers) Data Exchange Format 

The POP Manager can receive information about certain and/or every user 
connection from the servers in order to: 

• Calculate the real-time failure rate for certain and/or all the POPs that are 
being used, which can be used by the Pop Manager to determine the Interval 
Failure Rate (see Measurement Variables), which in turn can be used for 
POP ranking and DDO generation; and/or 

• Calculate the utilization rate for certain and/or all of the gateways that are 
being used, which can be utilized by the Pop Manager to determine the 
Interval Cost Rate (see Measurement Variables) of a gateway POP, which in 
turn can be used for POP ranking and DDO generation. 
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One possible protocol for the Pop Manager - Server Interaction is described 
below: 



1. START Message (from Server to Pop Manager) : 
5 The POPJJPDATE START message can be sent to the POP 

Manager at the beginning of a user's and/or client's connection. This 
message can contain information about the user's experience using one or 
more POPs. It can also include the list of the POPs to which the client has 
attempted to connect and whether the client succeeded in making a 
10 connection or not. The START message can have the following format: 

POPUPDATE <txno> START <client> <id of the member's service 
type> <popl :codel :codc2:...,pop2:codel :code2:. . .>, 

15 where: 

• <txno>: a unique string that can identify the user's 
connection; it can be used to match the message that indicates 
the end of the user connection. 

• <client>: astring that can indicate the connection type. 

20 • <id of the member's service type>: a string that can indicate if 

the user is using the free or paying service. 

• <popl:codel:code2:... > pop2:codel:code2:..>: a string that can 
provide information about the user's experience with the 
POPs into which the user has tried to dial; the codes can 

25 identify the different actions that occurred each time the user 

tried to connect (e.g., busy, timeout, no dial tone, success). 
The servers can receive this information from the clients via 
the Network String (see below). 



30 



2. 



SUCCESS / FAILURE Message (from PopManager to Server) 
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The Pop Manager can reply with "Success" or "Failure" after it 
receives the START message. This message can have the following format: 

FAILURE 

or 

SUCCESS <txno> <pop state> 

The FAILURE message can indicate that the START message could not be 
processed successfully. This might occur, for example, when the client is 
reporting an invalid POP. 

The SUCCESS message can indicate that the START message proceeded 
successfully. It also can include information about the (failure) state of the 
POP to which the user and/or client connected. 

3. END Message (from Server to Pop Manager) 

The END message can be sent to the Pop Manager when the user and/or 
client connection ends. This message can allow the POP Manager to know 
the number of concurrent connections for a given POP (this information can 
be used to determine the Interval Cost Rate required by the DDO generation 
algorithm). The END message can have the following format: 

POPUPDATE <txno> END 

4. SUCCESS Message (from the POP Manager to Server) 

This message can be the reply from POP Manager after receiving the END 
message. It can have the following format: 

SUCCESS <txno> 
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POP Ranking Procedure 

The Pop Manager can rank (sort) certain and/or all POPs in certain 
and/or every cluster and can update their DDOs accordingly. The ranking 
procedure, which can take place on a regular and/or irregular basis, can 
include the following steps: 

1 . Get the next available Pop Cluster from the Pop Cluster List. 

2. Get the list of all POPs - and their DDOs - that belong to the 
particular Pop Cluster from the database management system. 

3. Rank the POPs by comparing each POP's performance for every 
protocol and for every time interval (see below Measurement Variables" 
and "Comparison Techniques"). 

4. Update the variables that are used to generate the DDOs according to 
the new rankings. 

5. Generate new DDOs and update the database management system. 

6. Go to step 1. 

Measurement Variables 

The POP Manager can use the following measurement variables ("metrics*') 
to perform the comparison: 

• Interval Failure Rate - the POP's failure rate during a particular time 
interval for a particular protocol (example: the failure rate for free web 
connections might be 20% between 14:00 and 14:30 and 30% between 14:30 
and 15:00). This failure rate can be determined using the historical failure 
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data, which can be obtained from the database management system, as well 
as the real time performance data, which can be collected from the servers 
(see "Pop Manager - Server Interaction"). Depending on how much 
importance is given to performance, the interval failure rate can be the 
highest, the lowest, or some other weighted combination of the historical and 
real-time failure rates. 

• Interval Cost Rate - the POP's cost rate during a particular time 
interval for a particular protocol. The cost rates can be: 

• Metered. The POP Manager can use the best rate for the particular 
interval (if there are thresholds - rate changes when usage goes over a 
certain limit - the POP Manager can assume the lowest rate). 

• Per port. The POP Manager can use the best per port rate and can 
convert it to a metered rate by calculating the average interval usage for a 
specified time period, e.g., two weeks. 

• Failure threshold - the failure threshold can be a fixed percentage 
configurable value that can define a limit that gives meaning to a POP's 
failure rate. A high threshold limit can emphasize the importance of cost. 
Such a high threshold limit might only be tolerable if the POP's cost was 
very low. Alternatively, a low threshold limit can emphasize the importance 
of performance. 

Comparison Techniques 

The Pop Manager can use the following evaluation rules when comparing 
two POPs: 
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• If one of the interval failure rates is above the failure threshold, and 
the other one isn't, then the one that is below the limit can be prioritized 
higher. 

• If both interval failure rates are above the failure threshold, the one 
with the lower failure rate can be prioritized higher. 

• If both interval failure rates are below the failure threshold, the one 
that has the lower interval cost rate can be prioritized higher. 

Client - Server Data Exchange Format 



Client to Server 

During each successful connection to the server system, the client 
1 5 system can upload the following information: 

• The Network String. 

• The Connection History Log File. 

• Dialdata Information. 

20 Network String 

The network string can have the following format: 
<SRO{/POP_INFO}|<Dialable Form> 

where: 

• <SRO is the source telephone number 
25 • <POPJNFO> can be a string containing the following information: 

1 . the destination telephone number (POP) 

2. the name of the carrier to which the POP belongs to 

3. any errors during the dialing attempt (e.g., busy, timeout, no 
carrier) 

30 • <Dialable Form> = [J|W]<Encoded Dial String> 
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J = can indicate the user has used the system to set dial 
preferences 

W = can indicate the user has used Windows to set dial 
preferences 

<Encoded Dial String> = is the dial string. The string can be 
preceded by T or V to indicate Tone or Pulse dialing followed by a 
series of digits and/or dialable characters (e.g., comma). 

An exemplary network string can be: 

<2125555555>/2125554545^TT,NC,BU/2015555555,WCO 
M|W<Dial String> 

This network string can indicate that the client called from 212-555- 
5555; that the client attempted to call 212-555-4545, the ATT local POP, 
twice and got no carrier the first time and a busy the second time; then it got 
through on 201-555-5555, a WorldCom POP, on the first try. The user used 
Windows to set dial preferences. 

The server can forward the network string to the Pop Manager. With 
enough users involved with the system, the Pop Manager can receive enough 
real-time data to get a statistically valid sample of which POPs are 
performing well, and which POPs are failing. This information can be used 
for POP ranking and, consequently, for DDO generation. 

Connection History Log File 

The connection history log file can contain more detailed information 
than the network string about certain and/or all of the connections (successful 
and unsuccessful) that the user and/or client has attempted since the last 
successful connection. This file can be processed by server software and the 
relevant information can be loaded into the database management system. 



WO 01/52084 



PCT/US01/00702 



17 

This information also can be used by the Pop Manager to calculate historical 
failure rates for the POP network. Those rates can be used for POP ranking 
and, consequently, for DDO generation. 

Dialdata Information 

The dialdata information can have the following format: 

<Client-dial-data-configuration> = <Last-time-number-selection>:<Phone- 
numbers> 

where: 

• <Last-time-number-selection> can be the time for the last time the 
current user has selected telephone numbers. The server can use this 
time to determine whether to force number selection or not (the idea is to 
prevent the user from making too many number (re)configurations). 



• <Phone-numbers> can be a list of the locally selected phone numbers 
and the server supplied numbers (specified in the DDO), which can have 
the following format: (:<Selected-number>+ \ <ServerSentnumber>) 

where: 

• <Selected-number> can be the number that the user 
has selected for dialing. 

• <ServerSent-number> can be the number sent down 
by the server as part of the DDO. 



Server to Client (The DDO String) 
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In response to the client information, the server can send the DDOs to the 
client. The format of the DDOs can be as follows: 

<DDO> = <Special> | <Dial-record> 

where: 

• <SpeciaI> can either be an empty set DDO, in which case the client will 
do nothing or a <Delete-DDO> ("0") in which case the client will delete the 
locally stored DDO. 

For example: 

<Special> = <Empty> | <Delete-DDO> 
15 <Empty> = M {} ,, |" H 

<Delete-DDO> = M 0" 

• <Dial-record> = <Dial Data version>V<Force-select-flag>V<Server 
20 SignaturoC.^POP-record^ 

where: 

• <Dial Data version> can specify a minimum Dial Data version 
number for which this DDO is supported. If, for example, "5.3" was 
25 specified in this field, the client would ignore processing of this DDO 

unless the local Dial Data version was 5.3 or greater. 



5 



10 



30 



• <Force-select-flag> = , 0 , | , r. If set (1), the client can clear out the 
current user-selected number and can force the user to reselect local pops 
the next time the user attempts to dial. 
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• <Server Signature> can be a string that the client will resubmit to the 
server. 

5 • <POP-record> = <POP-number>(TPOP-param). 

A <POP-record> can include a <POP-Number> followed by zero or 
more <POP-param> separated by a T character. A <POP-record> 
with no associated <POP-param> can indicate that the POP should be 
10 included in the display for number selection using the current locally 

stored <POP-param>. 

<POP-number> - 'XXX+XXX+XXXX' - where X = 0..9 or 
(for international numbers) *<City Code> <Rest of Number>* 

15 

• <POP-param> = <LN> | <POP-pair> 

• <LN> = "Location" = <string> 

20 • <POP-pair> = <Priority-pair> | <Time-period-pair> | 

<Location-pair> 

Priority-Pair 

The <Priority-pair> can specify rules for setting the "High" 
25 and "Low" priorities for a particular protocol. When 

encountered, the client can randomize a number between the 
"High" and the "Low" values to use as the calculated priority 
before sorting the list of selected numbers before dialing. 
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For example: POP A has a Priority Low = 35 and a Priority 
High = 50; POP B has a Priority Low = 25 and a Priority High 
= 60. When the client attempts to dial a number, it generates 
a random priority value for POP A which falls into the range 
of 35 and 50 and a random priority value for POP B that will 
fall into the range of 25 and 60. It will then sort these two 
numbers in ascending priority order and begin to dial based 
on this resulting sort. Thus, 

1 . The client generates a priority of 40 for POP A and a 
priority of 30 for POP B. Thus, POP B is dialed first. 

2. The client generates a priority of 37 for POP A and a 
priority of 42 for POP B. Thus, POP A is dialed first. 

3. The client generates a priority of 48 for POP A and a 
priority of 48 for POP B. Either POP may be dialed first 

The following definition is given for a Priority-Pair: 

• <Priority-Pair> = <ProtocolxPriority Type^^Priority 
Value> 

where: 

• <Priority Type> can be either 'H' or 'L' (high or low) 

• <Priority Value> can be any integer between 0 an 99 

Time-Period-Pair 

A <time-period-pair> can define a data structure that 
encapsulates priority alterations based on specific time ranges: 
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• <Time~period-pair> = <Header-letterxlndex> , = , <Value> 
where: 

1. <Index> is the index of the time period. 

2. <Value> = <Start time> | <Duration> | <Day of 
week> |<Protocol> | <Probability> | <Priority 
Adjustment 

where: 

• <Protocol>: can indicate the type of user and the type 
of connection for which the adjustment should be 
applied. 

• <Priority adjustments can indicate the change in 
priority for a given interval and/or protocol (it can be 
applied to the Upper and/or the Lower priorities). 

• <Start time>: can indicate the start of the time interval 
for which the priority adjustment should be applied. 

• <Duration>: can indicate the length of the time 
interval for which the priority adjustment should be 
applied. 

• <Probability>: can indicate the probability of applying 
the priority adjustment. 

• <Day of week>: can indicate the day of the week for 
which the priority adjustment should be applied. 

During DDO processing, the client can check to make 
sure the current time falls into the correct time restriction 
based on the "Time.Start" and "Time.Duration" specification. 
If the optional, i Time.Probability ,> field is present, the client 
can generate a random number between 0-100 and will only 
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invoke the priority adjustment if the random calculation is 
less than or equal to the "Time.Probability" field. Thus, for 
example, if the probability is 20, and the client randomly 
selects 30, the adjustment is not made. Likewise, for 
example, if the client had randomly selected 12, the 
adjustment would be applied. In this example, this can be 
viewed as similar to saying that the "Time. Adjustment" 
should be made only "Time.Probability" percentage of the 
time, thus if "Time. Adjustment" is -20 and 
"Time.Probability" is 30, it means that -2.0 is added to the 
fixed priorities only 30% of the time. 

Location Pair 

LN = <Any String> 

DDO Example 

Consider the components of the following DDO string: 

5. 1 7: 1 :* :71 8+1 23+4567|FL=50|^^ 

|Yl==3B|Bl=8|Sl=c|Dl=o|Al=89|P2=JF|Y2=7|B2=61 |S2=A|D2=R|A2=-68 

• 5.17 — can indicate that the minimum supported dialdata file version 
is 5.17 (all clients with dialdata version 5.16 or lower will not apply this 
DDO). 

• 1 - can indicate that the client will force number selection the next time 
the user attempts to dial (either to get mail, connect to the web, etc.) 

• * - can indicate that the client will send this string unaltered to the server 
each time a connection is made. 

• 718+123+4567 - can indicate that the client expects the following 
parameters to refer to POP 718-123-4567: 
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• FL=50 - can indicate that the free mail Priority Low = 50 

• FH=78 - can indicate that the free mail Priority High = 78 

• 718+123+4588 - can indicate that the client expects the following 
parameters to refer to POP 71 8-123-4588: 

• LN=Houston,_TX - can indicate that the POP location is Houston, 
TX. 

• P1=J - can indicate that the Timel connection type is paying web 

• , Y1=3B - can indicate that the Timel days=59d=01 1 101 1 = Sun, 
Mon, Wed, Thu, Fri. 

• Bl=8 - can indicate that the Timel probability is 8, which can 
indicate that there is only an 8% probability that this time definition 
adjustment will be applied. 

• Sl=c - can indicate that the Timel start = 0230 (2:30am) 

• Dl=o - can indicate that the Timel duration = 1 530 (1 5 hrs, 30 min) 

• Al =89 - can indicate that the Timel adjustment is 89 

• P2=JF - can indicate that the Time2 connection type is paying web 
and email 

• Y2=7 - can indicate that the Time2 days = 7d = 00001 1 1 = Sun, Mon, 
Tue 

• B2=61 - can indicate that the Time2 probability = 61 

• S2=A - can indicate that the Time2 start = 0000 (12:00 am) 

• D2=R - can indicate that the Time2 duration = 1 800 (1 8 hours) 

• A2=-68 - can indicate that the Time2 adjustment = 68 
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Thus, in this example, during the next phone number selection, only the 
numbers that were previously selected and 718-123-4567 and 718-123-4588 will be 
presented to the user in the "recommended" access numbers list. 

5 Additional Description 

With the above description in mind, various exemplary embodiments of the 
invention will be discussed, in particular, those corresponding to Figs. 1-8. 

Method 100 

W Fig- 1 is a flowchart of an exemplary embodiment of a method 1 00 of the 

present invention. Method 100 can begin at activity 1010 by identifying access 
points for a client to access a communications network. The identified access points 
can be tailored for a specific client location. 

At activity 1020, metrics can be obtained for the access points. At least one 

15 of the metrics can be a real-time performance metric. The metrics can also include 
cost, historical failure, time-based, protocol-based, and/or user-based metrics. Any 
of the metrics can be received, determined, calculated, and/or look-up. For example, 
a historical failure metric can be received from the client in the form of a connection 
history log file. 

20 At activity 1030, the metrics can be evaluated by applying an evaluation 

algorithm and evaluation criteria to the metrics. At activity 1040, the access points 
can be prioritized based on the results of the evaluation. At activity 1050, the 
prioritized access points can be provided to the client. 

25 Method 200 

Fig. 2 is a flow diagram of an exemplary embodiment of a method 200 of the 
present invention. Method 200 can begin at activity 20 10 by a user attempting to 
log-on to a server. At activity 2020, the client software can make a determination 
regarding whether it is necessary to reselect the POPs. If not, the method can 
30 continues at activity 2040. If reselection of POPs is necessary, at activity 2030, the 
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client can ask the user to select some POPs from a list of POPs. The list of POPs 
can be those received from the server during the previous session. 

At activity 2040, the client can make a determination regarding whether a 
server is available. If not, at activity 2050, the client can make a determination 
5 whether to abort. If the decision is made not to abort, the method can continue at 
activity 2010. If the decision is made to abort, at activity 2060 the aborted network 
string can be saved to the logfile. 

If a server is available, at activity 2070 the client can send the logon 
information to the server. At activity 2080, the server can receive the logon 
10 information. At activity 2090, the server can send some log-on information to the 
POP manager, and/or can send all log-on information to the database. 

At activity 2100, the POP manager can send a reply to the server containing 
the current state of the user(s) POPs. At activity 21 10, the server can compute 
and/or generate a DDO string. That DDO string can contain: 
15 1 . A flag indicating the necessity of reselection; 

2. Priorities of POPs that were selected; 

3. A list of non-selected POPs that are likely to be local to the user's current 
location. 

20 At activity 2120, the server can send the new DDO string to the client At 

activity 2130, the client can parse the DDO string and overlay the DDO string onto 
the dialdata file. 

At activity 2140, the client can make a determination regarding whether the 
POP state is acceptable. If so, the user can be allowed access to the server. If not, at 

25 activity 2160, the client can terminate the current connection. Following 

termination, at activity 2170, the client can make a determination regarding whether 
to auto-reconnect. If not, method 200 can continue at activity 20 10. Otherwise, at 
activity 2180, the client can determine a new access number having the highest 
priority, and attempt to connect via that access number. Then, method 200 can 

30 continue at activity 2040. 
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Method 300 

Fig. 3 is a flow chart of an exemplary embodiment of a method 300 of the 
present invention. At activity 3010, the user can provide a source number, 
5 indicating the telephone number from which the user is dialing. The user can 
provide the source number during account creation or following a change of the 
user's location. At activity 3020, the client software can dial into the server using a 
toll-free telephone number and provide the source number to the server. At activity 
3030, the server can compute a list of local access numbers corresponding to the 
1 0 source number, the local access numbers being a subset of access numbers in the 
dialdata file. 

Method 400 

Fig. 4 is a flow chart of an exemplary embodiment of a method 400 of the 

15 present invention. At activity 4010, a user can attempt to connect to the server. At 
activity 4020, the client can make a determination regarding whether reselection of 
the POPs is necessary. If a reselection of the POPs is necessary, at activity 4030 the 
client can ask the user to select some POPs. These POPs can be selected from a list 
of local access numbers that were sent from the server in the previous session. If the 

20 user is attempting to connect from a new location, the client can use the new 
location's area code to offer POPs associated with that area code. 

If reselection of POPs is not necessary, at activity 4040, the client can iterate 
through the POP list and can compute priorities. If no DDO exists for a POP, the 
basic priorities from the dialdata file can be used. At activity 4050, the client 

25 software can place the access numbers in a priority queue. At activity 4060, the 
client can dial the access numbers in order of priority until there is successful 
connection or an abort. At activity 4070, the client can connect to the server. At 
activity 4080, the client can receive the most up-to-date DDO string. At activity 
4090, the client can parse the DDO string and can overlay the dialdata with the DDO 

30 string. The DDO string can contain new priority information. 
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Method 500 

Fig. 5 is a flow chart of an exemplary embodiment of a method 500 of the 
present invention. At activity 5010, the client can write data to a log file. That data 
5 can build a log file that contains the entire connection history, including successful 
and unsuccessful connections. At activity 5020, the client can up-load the log file 
when the user is successfully connected to the server. At activity 5030, the server 
can load a comprehensive log file into the database. At activity 5040, the server can 
send real time connection data to the POP manager to be evaluated. 

10 

Method 600 

Fig. 6 is a flow chart of an exemplary embodiment of a method 600 of the 
present invention describing a server system for computing DDO's. At activity 
6010, the POP manager can obtain a list of all clusters from the database. At 

15 activity 6020, the POP manager can collect real time data about the state of the 
networks from the servers. At activity 6030, the POP manager can obtain the POP 
cost rate information from the database. At activity 6040, the POP manager can 
obtain historical failure rates for each POP from the data base. At activity 6050, the 
POP manager can request the list of POPs and their DDO's for the next cluster on 

20 the list from the database. At activity 6060, the POP manager can rank the POPs 
using cost information, historical information, and/or real time failure rate 
information, any of which can be available on a per interval and/or per protocol 
basis. 

At activity 6070, the POP manager can modify the DDO's according to the 
25 new rankings. At activity 6080, the POP manager can update the database 

management system with any DDO's that have changed. At activity 6090, the POP 
manager can make a determination regarding whether the day is over. If the day is 
not over, method 600 can continue at activity 6050. If the day is over, method 600 
can continue at activity 6040. 



30 
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System 700 

Figure 7 is a block diagram of an exemplary embodiment of a system 700 of 
the present invention. As an initial matter, it suffices to say that, using the 
description of methods 100-600, one of ordinary skill in the art can implement the 
5 functionality of methods 100-600 via system 700 utilizing any of a wide variety of 
well-known architectures, hardware, protocols, and software. Thus, the following 
description of system 700 can be viewed as illustrative, and should not be construed 
to limit the implementation of any of methods 100-600. 

One or more client information devices 7010 running the client software can 

10 be coupled to a network 7020. Also coupled to network 7020 can be one or more 
server information devices (servers) 7030. One or more POP manager information 
devices 7040 running the POP manager software 7045 can likewise be connected to 
network 7020, as can one or more database server information devices 7050, each 
serving one or more databases 7055. 

15 Any client 7010 can provide to any server 7030 a network string and/or a log 

file, and/or can receive from that server 7030 a DDO string. Any server 7030 can 
provide a network string to the POP manager software 7045 and/or can receive a 
POP state from POP manager 7045. Any server 7030 can provide a log file to 
database 7055 and/or can receive from database 7055 a DDO. Database 7055 can 

20 provide a POP list, failure information, cost information, and/or a cluster list to POP 
manager 7045, which can compute the DDO's. POP manager 7045 can provide to 
database 7055 those computed DDO's. 

Although shown running on a dedicated POP manager information device 
7040, POP manager 7045 can run as a process and/or daemon on any server 7030. 

25 Similarly, although shown being served by a dedicated database server 7050, 

database 7055 can be served by any server information device 7030 or by the POP 
manager information device 7040. 

Network 7020 can have any architecture, including a direct connection, a 
local area network, a wide area network, a public switched telephone network, the 

30 Internet, an intranet, an extranet, a virtual private network, etc., and/or a 
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combination thereof Network 7020 can be a packet-switched, a circuit-switched, a 
connectionless, or connection-oriented network or interconnected networks, or any 
combination thereof. Moreover, a transmission media of network 7020 can take any 
form, including wireline, satellite, wireless, or any combination thereof In certain 
5 embodiments, the transmission media of network 7020 can be limited to those that 
support the secure transmission of data. 

From a hardware standpoint, any client information device 7010 can be, for 
example, a landline or wireless telephone, facsimile, personal computer, 
workstation, personal information manager, personal digital assistant, handheld 

10 computer, data terminal, or other similar device. Any information device 7030, 
7040, and/or 7050 can be, for example, a personal computer, such as a desktop 
computer, laptop computer, handheld computer, or other similar device. Any 
information device 7030, 7040, and/or 7050 also can be a workstation, dedicated 
server, mini-computer, mainframe, or other similar device. 

15 Database 7055 and/or other databases of system 700, can have a flat file or a 

relational organization, and a centralized or distributed architecture. For instance, 
those of skill in the art can tailor products such as an SQL database to provide at 
least some of the functionality of methods 100-600 and system 700. One supplier of 
such database products is Oracle Corporation, of Redwood Shores, CA. 

20 In certain embodiments, software standards and protocols such as EDI, FTP, 

HTTP, SGML, HTML, XML, cXML, XSL, SSL, WML, WAP and/or Bluetooth, 
etc., can be utilized for at least some communications within system 700. 
Additionally, system 700 can utilize platform-independent and/or network-centric 
software tools such as, for example, CGI, Java, and/or JavaScript, etc., as well as 

25 tools such as VisualBasic, C, C++, etc.. 



Device 800 

Figure 8 is block diagram of a exemplary information device 800 of the 
present invention. Information device 800 can symbolize any information device 
30 7010, 7030, 7040, and/or 7050. Information device 800 can include well-known 
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components such as one or more network interfaces 8100, one or more processors 
8200, one or more memories 8300 containing instructions 8400, and/or one or more 
input/output ("I/O") devices 8500. 

In one embodiment, network interface 8 1 00 can be a telephone, a traditional 
5 data modem, a fax modem, a cable modem, a digital subscriber line interface, a 
bridge, a hub, a router, or other similar devices. 

In one embodiment, processor 8200 can be a general-purpose 
microprocessor, such the Pentium series microprocessor manufactured by the Intel 
Corporation of Santa Clara, California. In another embodiment, the processor can 
10 be an Application Specific Integrated Circuit (ASIC) that has been designed to 

implement in its hardware and/or firmware at least a part of a method in accordance 
with an embodiment of the present invention. 

In one embodiment, memory 8300 can be coupled to a processor 8200 and 
can store instructions 8400 adapted to be executed by processor 8200 according to 
15 one or more actions of any of methods 100-600. Memory 8300 can be any device 
capable of storing analog or digital information, such as a hard disk, Random Access 
Memory (RAM), Read Only Memory (ROM), flash memory, a compact disk, a 
magnetic tape, a floppy disk, etc., and any combination thereof. 

In one embodiment, instructions 8400 can be embodied in software that can 
20 take any of numerous forms that are well known in the art. In one embodiment, I/O 
device 8500 can be an audio and/or visual device, including, for example, a monitor, 
display, keyboard, keypad, touch-pad, pointing device, microphone, speaker, video 
camera, camera, scanner, and/or printer, etc., and can include a port to which an I/O 
device can be attached, connected, and/or coupled. 
25 The present invention provides devices, systems, and methods for improving 

and/or optimizing client access to a communication network. Although the present 
invention has been described with respect to several exemplary embodiments, there 
are many other variations of the above-described embodiments that will be apparent 
to those skilled in the art, even where elements have not explicitly been designated 



WO 01/52084 



PCT/US01/00702 



31 

as exemplary. It is understood that these modifications are within the teaching of the 
present invention, which is to be limited only by the claims appended hereto. 
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What Is Claimed Is: 

1 . A method for optimizing client access to a communication network, comprising 
the activities of: 

identifying a plurality of access points for a client to access a 
communication network from a specified location; 

obtaining a plurality of metrics, including a real-time performance 
metric, for each of the plurality of access points; 

determining, using a processor, priority information for each of the 
plurality of access points based on the plurality of metrics for each of the 
plurality of access points; 

providing the priority information regarding the access points to the 

client. 

2. The method of claim 1 , further comprising receiving logon information from the 
client. 

3. The method of claim 1, further comprising receiving connection history 
information from the client. 

4. The method of claim 1 , further comprising providing initial priority information 
regarding the access points to the client. 

5. The method of claim 1, further comprising receiving at least one of the plurality 
of metrics. 

6. The method of claim 1 , further comprising receiving at least one of the plurality 
of metrics from the client. 
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7. The method of claim I, further comprising determining at least one of the 
plurality of metrics. 

8. The method of claim 1, further comprising looking-up at least one of the 
plurality of metrics. 

9. The method of claim 1, further comprising calculating at least one of the 
plurality of metrics. 

10. The method of claim 1, further comprising evaluating the plurality of access 
points based on the plurality of metrics for each access point from the plurality 
of access points. 

11. The method of claim 1, further comprising obtaining an evaluation algorithm to 
apply to the plurality of metrics for each access point from the plurality of access 
points. 

1 2. The method of claim 1 , further comprising obtaining evaluation criteria to apply 
to the plurality of metrics for each access point from the plurality of access 
points. 

13. The method of claim 1, further comprising assigning a priority to each of the 
plurality of access points based on an evaluation of the plurality of metrics for 
each access point. 

14. The method of claim 1, further comprising sorting the plurality of access points 
according to at least one of the plurality of metrics. 

1 5. The method of claim 1, further comprising ranking the plurality of access points 
according to the priority information. 
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16. The method of claim 1, further comprising assigning a priority to each of the 
plurality of access points according to a ranking of the plurality of access points. 

17. The method of claim L, wherein the plurality of metrics includes a cost metric. 

18. The method of claim 1, wherein the plurality of metrics includes a historical 
failure metric. 

19. The method of claim 1, wherein the plurality of metrics includes a time-based 
metric. 

20. The method of claim 1 , wherein the plurality of metrics includes a time interval- 
based metric. 

21. The method of claim 1, wherein the plurality of metrics includes a protocol- 
based metric. 

22. The method of claim 1, wherein the plurality of metrics includes a user-based 
metric. 

23. The method of claim 1, wherein the plurality of access points are evaluated 
based at least in part on a cost metric for each of the plurality of access points. 

24. The method of claim 1, wherein the plurality of access points are evaluated 
based at least in part on a historical failure metric for each of the plurality of 
access points. 
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25. The method of claim 1, wherein the plurality of access points are evaluated 
based at least in part on the real-time performance metric for each of the 
plurality of access points. 

26. The method of claim 1, wherein the prioritized list is based upon the evaluation 
of the plurality of metrics for each access point from the plurality of access 
points. 



27. The method of claim 1, wherein the real-time performance metric is based upon 
a real-time failure rate. 

28. The method of claim 1, wherein the real-time performance metric is based upon 
an interval failure rate. 

29. The method of claim 1, wherein at least one of the plurality of metrics is 
obtained from a connection history log. 

30. A machine-readable medium storing instructions for activities comprising: 

identifying a plurality of access points for a client to access a 
communication network from a specified location; 

obtaining a plurality of metrics, including a real-time performance 
metric, for each of the plurality of access points; 

determining priority information for each of the plurality of access points 
based on the plurality of metrics for each of the plurality of access points; 

providing the priority information regarding the access points to the 

client. 

31 . An apparatus for optimizing client access to a communications network, 
comprising: 
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means for identifying a plurality of access points for a client to access a 
communication network from a specified location; 

means for obtaining a plurality of metrics, including a real-time 
performance metric, for each of the plurality of access points; 

means for determining priority information for each of the plurality of 
access points based on the plurality of metrics for each of the plurality of access 
points; 

means for providing the priority information regarding the access points 
to the client. 

32. A computer-implemented system for optimizing client access to a 
communications network, comprising: 

an access point management routine adapted to obtaining a plurality of 
metrics, including a real-time performance metric, for each of a plurality of 
identified communication network access points; 

an evaluation routine adapted to determine priority information for each 
of the plurality of access points based on the plurality of metrics for each of the 
plurality of access points; 

a communication routine adapted to provide the priority information 
regarding the access points to the client. 

33. A method for obtaining optimized access to a communication network, 
comprising the activities of: 

connecting to the communication network via one of a plurality of access 

points; 

providing connection history information to the communication network; 
receiving a prioritized list of access points for future connections. 

34. The method of claim 33, further comprising selecting at least one access point 
from the plurality of access points. 
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35. The method of claim 33, further comprising selecting a subset of access points 
from the plurality of access points. 

36. The method of claim 33, further comprising attempting to connect to the 
communication network via one of the plurality of access points. 

37. The method of claim 33, further comprising attempting to connect to the 
communication network via a selected one of the plurality of access points. 

38. The method of claim 33, further comprising attempting to connect to the 
communication network via a highest priority access point from the prioritized 
list of access points. 

39. The method of claim 33, further comprising attempting to connect to the 
communication network via a highest priority access point from a selected subset 
of access points from the prioritized list of access points. 

40. The method of claim 33, further comprising providing logon information to the 
communication network. 

41 . The method of claim 33, further comprising replacing a pre-existing list of 
access points with the received prioritized list of access points. 

42. The method of claim 33, wherein the access points on the prioritized list are 
ranked based on a plurality of metrics for each of the plurality of access points. 

43. A machine-readable medium storing instructions for activities comprising: 

connecting to the communication network via one of a plurality of access 

points; 
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providing connection history information to the communication network; 
receiving a prioritized list of access points for future connections. 

44. An apparatus for obtaining optimized access to a communication network 
comprising; 

means for connecting to the communication network via one of a 
plurality of access points; 

means for providing connection history information to the 
communication network; 

means for receiving a prioritized list of access points for future 
connections. 

45. A machine-readable data structure, stored on a machine-readable medium, for 
optimizing client access to a communication network, the structure comprising at 
least one access point identifier having at least one priority adjustment value. 
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